Ideally, I think this should be set up in a GitHub Action that creates the file, and creates the issue as well. I'd opt for it to be created on the 28th of the month, that way it's at least a few days before the beginning of the next month. We can probably start with this as a base though :)

got a ci version on my repository: ci code, resulting PR

I'm ok with triggering that on the 28th of each month, that fits with my thoughts on #1417 (comment).

I think if I were a maintainer, I'd still prefer this to be:

• manually triggered to keep a control on timings, be able to run it again if fails, allow some flexibility if needed.
• changes go through a PR, to double check the content is OK,

There are still things we could add: fill the date, create the coordination issue...

Created a fully automated alternative: #1464

#1464 seems great but can be seen as complementary to this pull request:

• This PR (#1457) prepares the new file (blog entry as a draft)
• #1464 prepares a new issue

@Vrixyz oh, I didn't realize that your script also prepared the post itself, that's pretty cool!

Wouldn't it be easier to have this as a GH Action as well? Remember you can also manually trigger those.

Added the newsletter generation as well now :)

Per @Vrixyz's feedback, #1464 includes a shell script now ✨